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@ In a transaction processing system that in- 
cludes a plurality of client processes (40) coup- 
led to a server process (42), the server process 
supports execution of transadlons generated 
by the client processes. The server process 
includes, for each dient process being served, 
one or more transaction message control 
mechanisms. Each transaction message control 
mechanism includes a named processing 
object that includes a name identifying the 
object. The named processing object also in- 
cludes an input process that receives all trans- 
action request messages naming the object and 
identifying the originating client process. The 
input process dispatches a transaction process 
for each transaction request message received 
from the respective client process. Each trans- 
action process oversees transaction execution 
and receives transaction output A transaction 
process provides a transaction output message 
for the originating client process. In a non- 
sync'd mode of operation, transaction proces- 
ses may synchronously send transaction output 
messages to dient processes. In a synchronized 
mode of operation, one transaction process at a 
time sends output messages under control of 
an output process in the named processing 
object The transaction message control 
mechanisnrw provide a bi-directional transac- 
tion message flow between server and dient 
processes. 
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The invention relates to transaction processing, and more particularly to a transaction processing system 
of the client/server type in which a client process creates a mechanism in a server process that controls bi- 
directional transaction message traffic between the client and server processes. 

A transaction has been defined as a logical unit of work by C.J. Date in his work, INTRODUCTION TO 

5 DATABASE SYSTEMS, Volume I (Addison- Wesley, September, 1985). Date particularly taught that a trans- 
action in the database context consists of a sequence of operations by which a database is transformed from 
one consistent state to another consistent state. A transaction processing system guarantees that a transaction 
will either complete the transformation of a database into a new consistent state, or return the database to the 
consistent state at which the transaction began. 

10 A particularly useful architecture for implementing transaction processing in distributed systems is the cli- 

ent/server model that is described in H.M. Deitel's OPERATING SYSTEMS (Addison-Wesley, 1990). In this 
model, clients denote service consumers in the form of client processes, while servers are processes that pro- 
vide the services. In a typical database system that provides transaction-based access to a plurality of users, 
users enter database requests through client processes. The client processes engage the server process in 

15 the form of a database management system to service the user request according to a predetenmined trans- 
action protocol. 

From the standpoint of client and server processes, transactions may be considered as "objects". As ob- 
jects, transactions encompass the procedures and data necessary to satisfy a user request. As objects, trans- 
actions can be directly manipulated by clients and servers. The preferred mode of handling transaction objects 
20 is by messages that specify a particular type of manipulation. In this regard, a user request for reading records 
from a database may manipulate a transaction by specifying that the transaction must re^ad the database and 
by providing parameters that establish where the reading is to take place, what records are to be read, etc. 
The transaction reports the outcome of the manipulation by returning a response message including the results 
of the operation. 

25 Typically, objects are described by data structures that are referred to as "names". Current techniques of 
object-oriented programming recognize a "named processing object" as an object having a name and including 
one or more procedures. 

Atransaction message implies a source and a destination. Acurrent database management system, such 
as the IMS product available from INTERNATIONAL BUSINESS MACHINES CORPORATION, distinguishes 
30 these end points by the use of logical terminals (LTERMs). An LTERM provides a queue where transaction 
output from the IMS product resides. Eventually, the IMS product makes the connection between the queue 
and a physical node that will receive the queued output In the client/server model, the IMS product is consid- 
ered the server process. Such database systems do not afford a client process with a mechanism to control 
transaction message flow by specifying the source and destination of a transaction message. 
35 Viewed from another aspect, the LTERM capability of the IMS product provides a uni-directional (server- 

to-client) pipeline that can only be manipulated by the server. In this respect, an LTERM suggests the pipe 
structure used in UNIX® systems (UNIX is a registered trade mark of Novell Inc.). Pipes may be objectified 
by names. They provide uni-directional, FIFO data transfer between processes and include the capability of 
interprocess synchronization. Two pipes oriented in opposite directions between client and server processes 
40 can provide bidirectional message flow, but entail two processing objects, only one of which can be manipu- 
lated by the client process. 

Manifestly, the more time a server must spend in transaction message processing, the less efficient it 
will be in processing transactions. Accordingly, there is a need in transactton- based systems of the client/ser- 
ver type to provide a mechanism that will allow any client process to objectify a transaction and to manipulate 
45 the transaction object by messages in a bi-directional message pipeline. Viewed from one aspect the present 
invention provides a transaction processing system comprising: 

a plurality of client processors for generating transaction request messages, each transaction request 
message including a request to execute a transaction and an object name; 

a server process for executing transaction requests contained in transaction request messages from 
50 the client processes; 

an interprocess message exchange facility coupled to the client processes and the server process for 
providing client process transaction request messages to the server process and providing transaction output 
messages to the client processes; 

an input process in the named processing object for receiving all transaction request messages that in- 
55 dude the object name and the identification at the respective client process; and 

dispatch means in the input process for dispatching a transaction process in response to a transaction 
request message, each transaction process dispatched by the dispatch means being for receiving a transaction 
request message and for initiating a transaction for execution. 
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